home *** CD-ROM | disk | FTP | other *** search
Text File | 1990-04-06 | 1.6 KB | 43 lines | [TEXT/GEOL] |
- Item forwarded by A33 to A34
-
- Item 4670984 2-April-90 09:33PDT
-
- From: ALGER Alger, Jeff,VCA
-
- To: DAWSON.M Dawson, Mark
-
- cc: MACAPP.TECH$ MacApp Technical
-
- Sub: Re: Success() and…
-
- Mark,
-
- Look in the current issue of Frameworks for a series of links on the subject.
- (This issue is in the mail to most MADA members now.) However, I will replay
- the essence of the idea. Suppose you have a block of code which may err in
- some relatively unpredictable way. Call this code CodeBlock. Then, in
- pseudocode, the idea of a failure handler to implement the following strategy:
-
- IF CodeBlock will not fail THEN
- CodeBlock
- ELSE
- DoSomethingElse
-
- Of course, it is not possible to test in advance whether CodeBlock will succeed
- or fail. Instead, the failure handler implements the strategy by saving the
- state of the registers at the time you call CatchFailures, then branching to
- your error handler when an error occurs. You are responsible for saving the
- state of the program (other than registers) prior to calling CatchFailures and
- restoring it, then calling DoSomethingElse when (if) your handler is called due
- to a failure. In other words, you should be prepared to restore things when
- your failure handler is called as if the CodeBlock had never been started.
-
- On the specific question of the "fi" argument: this is used by the MacApp
- mechanisms to store register values and the address of your handler.
-
- Regards,
- Jeff Alger
- Exis
- A Technology Firm of KPMG Peat Marwick
-
-